The present invention pertains to the transmission of voice, video or other information over the Internet in an interactive user session and, more specifically, to a method and apparatus for assuring that when one user agent ceases to participate in the session, the other user agent terminates its participation in the session.
The Session Initiation Protocol (“SIP”) is a signaling protocol that is employed in the set up and termination of multimedia sessions and Internet telephony calls and is described with particularity in the Internet Engineering Task Force (“IETF”) Request for Comments (RFC) 3261 dated June 2002, which is incorporated herein by reference.
The SIP is a peer-to-peer protocol in which each endpoint or User Agent (UA) typically includes a User Agent Client (UAC) and a User Agent Server (UAS). A UAC initiates the establishment of an interactive session between the UAC and a UAS by forwarding a SIP request in the form of a SIP INVITE message to the UAS directly or through a proxy agent (which includes a proxy server and a proxy client) as known in the art.
More specifically, to establish a typical SIP session directly between a UAC and a UAS, the UAC sends a SIP INVITE request directly to a UAS. Upon receipt of the INVITE request, the UAS forwards a RESPONSE message to the UAC. The UAC then forwards an acknowledgement (ACK) to the UAS and the participants then initiate the session using the Real-Time Transport Protocol (RTP) for transport of media packets through an IP network.
Alternatively, as is known, the session may be established through a proxy agent. To establish a session through a proxy agent, the UAC initiating the session sends an SIP INVITE request to the proxy server and the proxy client forwards the SIP INVITE request to the UAS. Upon receipt of the SIP INVITE request at the UAS, the UAS forwards a RESPONSE to the proxy client and the proxy server forwards the RESPONSE to the UAC. The UAC forwards an acknowledgement (ACK) to the proxy server and the proxy client forwards the ACK to the UAS. A session is then established between the. UAC as the calling device and the UAS as the called device.
In either circumstance, once the session is established, media packets are exchanged via the Real-time Transport Protocol and RTP/RTCP packets are exchanged between the participants in the session. At the end of a session the participants typically terminate the session in an orderly manner as specified in the SIP standard RFC 3261.
A Voice over Internet Protocol (VOIP) call created using the SIP can end up in a “stuck” state if one of the endpoints leaves the session or ceases to participate in the session for any reason without notifying the other endpoint via appropriate SIP signaling. This usually occurs as the result of a software bug, a system crash or due to some other anomaly within the network. When one endpoint ceases to participate in the session without notifying the other endpoint, the surviving endpoint continues to send media packets employing the Real-Time Transport Protocol (RTP) to the non-participant. This becomes a problem when the non-participant, be it a UAC or a UAS, attempts to make a new call and attempts to re-use the RTP destination port to which the surviving endpoint is still sending RTP/RTCP packets. If the surviving endpoint from the broken session and another user agent are both sending RTP streams to the same RTP destination port, problems are likely to arise with the newly initiated session.
An optional part of the SIP specified in RFC 3261 specifies that “session timers” may be employed by each participant in a session to address the above-described problem of “stuck” calls. When session timers are employed, after a session is initiated, the endpoints exchange session timer INVITE requests periodically in order to determine whether the other endpoint is still an active participant in the session. While this technique addresses the “stuck call” problem when both call participants properly support the use of session timers, many devices do not support session timers. Additionally, due to programming errors, the RTP data stream is sometimes interrupted during the transmission of a session timer INVITE message. The interruption of the RTP data stream while audio/video packets are being exchanged can glitch the audio/video being communicated in the session. This periodic glitching of the audio/video can be annoying to the end users. Consequently, session timers, even when supported, are often purposely disabled, leaving the system vulnerable to stuck calls.
Accordingly, it would be desirable to be able to solve the “stuck call” problem without periodically causing glitches in the media stream.